Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-065

Text File | 1995-06-07 | 110.9 KB | 3,237 lines | [TEXT/R*ch]

C.S.M.P. Digest             Fri, 14 Oct 94       Volume 3 : Issue 65

Today's Topics:

        Books-Reference: opinions needed!!
        Changing to new toolbox routine names with MacPerl
        Cleanest way to turn AppleTalk on-off
        Dialog Edit text> 256 characters
        Fast zeroing on PPC
        Inside Mac on CD-ROM
        Q: Using PPC apps without Shared Libraries?
        Reading STR# resource - Pascal code



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users.  To search back issues
with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use
http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html.


-------------------------------------------------------

>From [e-mail] (Robert)
Subject: Books-Reference: opinions needed!!
Date: 24 Sep 1994 22:09:29 GMT
Organization: kind of sloppy actually....

I need YOUR opinion!  Here are some books that I've heard of, and I want to
know how they rate.  Also, let me know if you have any good suggestions on
where to get them (mail order or otherwise.)  Note that I'm interested in
books for people who know little or nothing about mac programming in general
(but who know something about programming on other platforms.)

Inside Macintosh: Overview - worth it or not?  necessary?  What Inside mac
books are absolutely essential for any mac programmer?

Power Macintosh Programming Starter Kit (book + CD)  Anyone used it?  Is it
useful for people who have, say, CW gold but no PowerPC?  What is the
"special"
version of MW CodeWarrior included on the CD like?  (i.e. how stripped down?)

Other books:  (How suitable for complete neophytes?  How "good" in general?)

Think THINK C by Dan Parks Sydow
Macintosh Programming for Dummies by Dan Parks Sydow
The C Programming Primer from Dave Mark
Learn C on the Macintosh by Dave Mark
Learn C++ on the Macintosh by Dave Mark
Symantec C++ Programming for the Macintosh  by ???
How to Write Macintosh Software, Third Edition
"Macintosh Programming Secrets" 2nd edition by ???
Debugging Macintosh Software With MacsBug

the Waite Group's C Primer Plus
the Waite Group's C++ Primer (or something like that)
C++ Primer (Addison Wesley)
C++ Programming Language (Addison Wesley)
K&R's The C Programming Language, 2nd Edition.


Any books I'm missing that might be useful for complete novices?

Thanks for your reply.  This info will be very useful to me and many others.
(I may start a "getting started with mac programming FAQ.")

@@@@@ Robert Stone ([e-mail])
@@@@@ Some Sort of Computer-Related Person, UGA - Extension Dairy Sci.
@@@@@ Windows - n. a software package designed to cure the DOS virus, but
        which proved to be ineffective.  While removing the 640K limit
        symptom, the system performance becomes degraded even further.
            Also increases chance of system crash and consumes additional
        disk space.


+++++++++++++++++++++++++++

>From [e-mail] ( nick.c )
Date: Sun, 25 Sep 94 01:28:48 GMT
Organization: The Pitt, Chemistry

In Article <36282p$[e-mail]>, [e-mail] (Robert)
wrote:


>Inside Macintosh: Overview - worth it or not?  necessary?  What Inside mac
>books are absolutely essential for any mac programmer?

    A good introduction to the general structure of the essentials of
      a mac program.  Read it - once.  Not necessary, but helpfull.

    The essential NIM?  Depends on what you're doing.  In general I'd
      say Toolbox, More Toolbox, Imaging with Quickdraw, and Files.
      I found "Text" very usefull, not sure I'd call it essential.
      Some folks say "Memory" is essential, not sure I'd agree.

>Power Macintosh Programming Starter Kit (book + CD)  Anyone used it?  Is it
>useful for people who have, say, CW gold but no PowerPC?  What is the
"special"
>version of MW CodeWarrior included on the CD like?  (i.e. how stripped
down?)

    A neat book, it discusses some issues unique to the Power Mac that
      I know of no other source for.  It also presents some unique mac
      programming techniques (eg Rez) that are not usually brought up
      in introductory books.  The version of CW included will only allow
      you to open existing projects, not create new ones.  There are
      example projects on the CD, so you have a fully functional environment
      for learning/evaluating CW - but you won't be able to use it to
      generate your own projects.  I'd recommend this book to someone
      who wants to familiarize themselves with the CW environment, or
      is considering buying CW, or who has an interest in programming
      for the powermac.  I would not recommend this for someone entirely
      new to mac programming.

>Other books:  (How suitable for complete neophytes?  How "good" in general?)
>
>Think THINK C by Dan Parks Sydow

    It's been highly recommended on the net, and Dan is a good author,
      but I haven't read it.

>Macintosh Programming for Dummies by Dan Parks Sydow
>The C Programming Primer from Dave Mark

    A little out of date, but it's what I learned with, and I'd still
      recommend it for someone who knows C but is unfamiliar with
      programming on the mac.  Written in plain old english,
      it presents the concepts and implementation of basic macintosh
      programming techniques such as how to use menus and how to
      manage windows.  It's still very relevant, and extremely well
      written.

>Learn C on the Macintosh by Dave Mark

    The mac toolbox is a collection of rom "tools" that you use to
      generate many of the common elements of the macintosh interface:
      both it's visible interface and it's "method" for dealing with
      user interactions.  A program is a recipe for getting a job
      done that the computer will read and follow.  You can tell the
      computer to use the "tools" in the rom toolbox as well as other
      actions but you have to tell the computer in a language it'll
      understand.  The most common language for creating these recipes
      on the mac is C.  You have to learn to a language before you
      can do anything else, if you choose to learn C, Dave Mark's book
      is a clear, effective, and well structured introduction to that
      language.  Recommended as the first book you buy to learn macintosh
      programming.

>Learn C++ on the Macintosh by Dave Mark

    C++ is a superset of C, and should not be the first language you
      learn.  This was one of two books I read when I learned C++,
      and I recommend it, however I'd consider this book the un-official
      "volume 2" to Dave Mark's _Learn C on the Macintosh_.  Learn
      C first, then learn the toolbox.  Program for a while, and when
      you're confident with that this book is a good intro to the joys
      and frustrations of a new *style* of programming called OOP.
      C++, an enhanced version of C, is a good choice to implement
      that style.

>Symantec C++ Programming for the Macintosh  by ???

    Eh.  A good introduction to the Symantec environment, and a handy
      reference - but not a must have.  It general learning the compiler
      is the easy part, learning what you can do with it - that's the
      art.

    Does re-introduce a lot of C++ concepts, but not the place to learn
      'em.

>How to Write Macintosh Software, Third Edition
>"Macintosh Programming Secrets" 2nd edition by ???

    A good, *fun* book that includes so many "in-jokes" it's hard
      to read with a straight face.  I don't think this is intended
      as a "first" book on the toolbox, but it's good supplemental
      reading - and a lot of fun to read.

>Debugging Macintosh Software With MacsBug
>the Waite Group's C Primer Plus
>the Waite Group's C++ Primer (or something like that)
>C++ Primer (Addison Wesley)
>C++ Programming Language (Addison Wesley)

    As close to the definitive reference on C++ as exists.  As I said
      above, don't start to C++, but when you want to learn C++ this is
      a must have.  Reads like stereo instructions, but an essential
      *reference*.

>K&R's The C Programming Language, 2nd Edition.

    The classic.  If you program in C, you have this book.  I wouldn't
      learn C from it, but I wouldn't learn C without it.

>Any books I'm missing that might be useful for complete novices?
>
>Thanks for your reply.  This info will be very useful to me and many others.
>(I may start a "getting started with mac programming FAQ.")

    Overdue, please do.

                                                -- nick



                                    _/   _/  _/  _/_/_/   _/   _/
     Interet: [e-mail]        _/_/ _/  _/  _/   _/  _/_/_/
      eWorld: nick                _/ _/_/  _/  _/       _/ _/
         CIS: 71232,766          _/   _/  _/   _/_/_/  _/   _/


+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 25 Sep 1994 03:43:25 -0000
Organization: Delphi Internet Services Corporation

[e-mail] ( nick.c ) writes:

>In Article <36282p$[e-mail]>, [e-mail] (Robert)
>wrote:
[snip]

>>Learn C on the Macintosh by Dave Mark

[explaination of mac programming paradigm deleted]
>      on the mac is C.  You have to learn to a language before you
>      can do anything else, if you choose to learn C, Dave Mark's book
>      is a clear, effective, and well structured introduction to that
>      language.  Recommended as the first book you buy to learn macintosh
>      programming.

>>Learn C++ on the Macintosh by Dave Mark

>    C++ is a superset of C, and should not be the first language you
>      learn.  This was one of two books I read when I learned C++,
>      and I recommend it, however I'd consider this book the un-official
>      "volume 2" to Dave Mark's _Learn C on the Macintosh_.  Learn
>      C first, then learn the toolbox.  Program for a while, and when
>      you're confident with that this book is a good intro to the joys
>      and frustrations of a new *style* of programming called OOP.
>      C++, an enhanced version of C, is a good choice to implement
>      that style.

[rest deleted]

I disagree.  There are much better books that assume no
platform-specifics which are better introductions to C and C++ as
languges.  Dave Mark's Learn C/++ on the Mac books are an incredible
waste of trees.

1.  They only teach you the very basics of the languges.
Platform-null books go into much greater detail.

2.  He doesn't know how to program effective C++ (or didn't at the
time he wrote the book).

3.  Both of these books are specific to programming DOS/Unix boxes
using Think C.  I repeat: there are much better books for this
purpose.

Such as:
C++ Inside Out
The Waite Group's stuff
Teach Yourself C++ by Al Stevens

I think almost any C/C++ book that is platform-null will do the job
well.

........................................................................
Chris Thomas, [e-mail], Project KillThinkRef @ Echo Software

+++++++++++++++++++++++++++

>From [e-mail] (AFC Susan)
Date: 25 Sep 1994 04:17:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

Re article <[e-mail]>, [e-mail] ( nick.c ):

  Thank you for your thorough response. Sorry I must disagree on
  these two books.

> > Learn C on the Macintosh by Dave Mark ...You have to learn to a
> language before you can do anything else, if you choose to learn
> C, Dave Mark's book is a clear, effective, and well structured
> introduction to that language.  Recommended as the first book you
> buy to learn macintosh programming....

  This book has the surface appearance of a new wonder drug, touted
  as containing the C language, a compiler, reference material, a
  glossary, and programming examples. Too bad people fall for slick
  packaging. It is really sad to see a discipline accepting of such
  nonsense, when a rock solid foundation is needed instead.

> > Learn C++ on the Macintosh by Dave Mark... C++ is a superset of
> C, and should not be the first language you learn.  This was one
> of two books I read when I learned C++, and I recommend it,
> however I'd consider this book the un-official "volume 2" to Dave
> Mark's _Learn C on the Macintosh_.  Learn C first, then learn the
> toolbox....

  Pardon the paraphrase. As a much brighter brain than mine said
  regarding plummeting educational standards in the USA, in
  Doonesbury, "Maybe we could call ourselves Programming High School
  and get away with it."

  Something tells me that continued recommendation of Mr. Mark's
  books, which is apparently based on his Primer fame, in
  professional circles like c.s.m.p is an emergency that just won't
  go away.

Susan Lesch (AFC Susan)
Forum Consultant, Macintosh Utilities Forum
America Online, Inc.

  Speaking only for myself and my colleagues. "You be me for a
  while. And I'll be you." --Paul Westerberg, and The Replacements,
  circa 1989.

+++++++++++++++++++++++++++

>From Gilles Dignard <[e-mail]>
Date: 25 Sep 1994 13:40:34 GMT
Organization: HookUp Communication Corporation, Oakville, Ontario, CANADA

In article <36282p$[e-mail]> Robert,
[e-mail] writes:
>Any books I'm missing that might be useful for complete novices?

Actually, your list is missing the two I consider were the most helpful
to me learning C++. Neither is Macintosh specific, though.

The first is essentially a textbook. It is "Classic Data Structures in
C++" by Timothy A. Budd, published by Addison Wesley, ISBN 0-201-50889-3.
What I found particularly useful were the numerous code snippets and
source to a large number of important classes that are included (Linked
lists, string classes, vectors, queues, matrices, etc.). Most
importantly, it isn't just a cookbook of classes, however. The classes
are discussed in detail, and while it may or may not be something new,
what the classes represent in a more general computational sense is also
discussed.

Once you get your feet wet, and want to know how to best use your
new-found C++ abilities, the book to get is "Effective C++ / 50 Specific
Ways to Improve Your Programs and Designs" by Scott Meyers, published by
Addison-Wesley, ISBN 0-201-56364-9. One of the best "programming" books
I've ever run across. A must-have for all C++ programmers.

- --------------------
####      /\      ####  Gilles Dignard - [e-mail]
####  ]\/\  /\/[  ####
####  \ \    / /  ####  The human mind treats a new idea the way the
####  /--------\  ####  body treats a strange protein; it rejects it.
####      ][      ####                   - P.B. Medawar
- --------------------

+++++++++++++++++++++++++++

>From [e-mail] (Howard Berkey)
Date: Sun, 25 Sep 1994 20:53:18 GMT
Organization: Psychonaut Foundation

In article <[e-mail]>, [e-mail] ( nick.c )
wrote:

> >Debugging Macintosh Software With MacsBug
> >the Waite Group's C Primer Plus
> >the Waite Group's C++ Primer (or something like that)
> >C++ Primer (Addison Wesley)
> >C++ Programming Language (Addison Wesley)
>
>     As close to the definitive reference on C++ as exists.  As I said
>       above, don't start to C++, but when you want to learn C++ this is
>       a must have.  Reads like stereo instructions, but an essential
>       *reference*.
>

ARM.  ARM.  ARM.   Must have.

(until I can get the ANSI standard, that is :-)

Really, the Annotated Reference Manual is as close to definitive as it gets
for C++, at least as a target for current compilers, which is what is
really important unless you can head-compile your code and speak in
assembler :-)

>
> >Thanks for your reply.  This info will be very useful to me and many
others.
> >(I may start a "getting started with mac programming FAQ.")
>
>     Overdue, please do.
>


Jon's is a good start at least...  you might check it out, he posts it
here regularly.

-H-

--
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Howard Berkey                                     [e-mail]
Segmentation Fault (core dumped)

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Mon, 26 Sep 1994 19:29:02 +0100
Organization: Royal Institute of Something or other

In article <363uki$[e-mail]>,
Gilles Dignard <[e-mail]> wrote:

>Once you get your feet wet, and want to know how to best use your
>new-found C++ abilities, the book to get is "Effective C++ / 50 Specific
>Ways to Improve Your Programs and Designs" by Scott Meyers, published by

May I pop in with a recommendation for "Writing Solid Code" by
Steve Maguire? Once you've gotten through your first C or C++
or even Pascal book, this book will teach you lots of good
habits which will help you a LOT. It also goes through known
problem areas, especially when writing C code, and tells you
what you can do about it.

Or maybe I should keep quiet about it and treat it as a secret
corporate advantage? :-)

Cheers,

                / h+


--
  Jon W$E4tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
  "Psychotherapist" - "Psycho-The-Rapist"
   Pure coincidence? You decide!


+++++++++++++++++++++++++++

>From [e-mail] (gary greenberg)
Date: 26 Sep 1994 01:39:36 GMT
Organization: Center for Instructional and Research Computing Activities

In article <36282p$[e-mail]>, [e-mail] (Robert)
writes:
>I need YOUR opinion!
    [massive snip]
>Any books I'm missing that might be useful for complete novices?
>
>Thanks for your reply.  This info will be very useful to me and many others.
>(I may start a "getting started with mac programming FAQ.")
>
>@@@@@ Robert Stone ([e-mail])

Here's advice from a _true neophyte_ fwiw,
In the last few months, I've spent a good deal of time in the books.
I've started at the ANSI C level 'cause I need it for work, and I'm
teaching myself for fun. I've read several Smalltalk books, some UNIX C,
and am working my way thru several Mac Programming books. Rather than
offer specific comments about any single book compared to another, I'll
post the following note cause I think *everyone* reading this list will
want the information included. There is an online source to these books;
several actually. Addison Wesley has an online Gopher, and probably a
WWW. O'Reilly and Associates does also. I don't have the A/W handy, but
O'Reilly is at [e-mail] for general questions (they do the *great*
Nutshell books -- I just finished their VI book and its A++). To
get their catalog, send mail to [e-mail], and to get info about
their gopher send to [e-mail]. Now, ...
for more Mac Specific books & everything else ...
    ____ begin included ______________
From:   MX%"[e-mail]" 22-SEP-1994 17:51:03.62
To:     me
Subj:   Softpro Internet Resources

[snip header; increase other's reading pleasure ;-) ]

===============================================================
 ... Below you will find additional information for
accessing our on-line resources such as our Gopher and Mosaic
Catalog services.
If you have any additional questions, feel free to e-mail, write,
 fax, or give us a call.

David Vins
Softpro
==================================================================
Softpro offers both on-line Gopher and World Wide Web/Mosaic services
complete with browse, search, and on-line order capabilities.
Our booklist is also availble via FTP.  To access these services,
follow the information provided below.

         FTP: -> Anonymous ftp to "ftp.std.com"
              -> Our booklist can be obtained as the following...
                 "customers/books/Softpro/booklist"

      Gopher: -> "gopher storefront.xor.com"
              -> Select the "Softpro Books" menu item.

  WWW/Mosaic: -> "xmosaic http://storefront.xor.com"
              -> Select the "Softpro Books" menu item.

              -> Mosaic for Windows/Mac users please note, our URL
                 (Universal Resource Locator) for Softpro is
                 "http://storefront.xor.com/"
================================================================

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- Softpro Books & Software                                      -=-
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= =
  - 112 Burlington Mall Rd.         Hours:  Mon-Fri   9am to 8pm  -
  = Burlington, MA 01803-5300              Saturday  10am to 6pm  =
  -                                          Sunday  12pm to 5pm  -
  =  Sales: +1.617.273.2919                                       =
  -    Fax: [phone]                                       -
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= =
-     E-Mail -> [e-mail]                           -=-
= WWW/Mosaic -> http://storefront.xor.com                         =
-     Gopher -> gopher storefront.xor.com                         -
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
__________________ End Included ____________________
The folks at SoftPro have it all; books on C, C++, LISP, Smalltalk,
UNIX, Windoze, whatever & the description of many books is also
on line -- lots of the FAQ is there for the _including_.
For ANSI C stuff, there are also online training courses avaliable,
go to rtfm at mit, look in the Usenet FAQs for comp.lang.c and
comp.lang.c++ -- they also include and rate books that are
basically platform independent. Of course, to really code on the
Mac you'll still need the Toolbox books at a minimum.

Well, I've already told you more than I know, but hey ...
at this price it's a good deal ;-)
Cheers,
Gary

+++++++++++++++++++++++++++

>From tblanch@lookout (Todd Blanchard)
Date: Mon, 26 Sep 1994 15:56:48 GMT
Organization: US WEST Information Technologies

Robert ([e-mail]) wrote:
: I need YOUR opinion!  Here are some books that I've heard of, and I want to
: know how they rate.  Also, let me know if you have any good suggestions on
: where to get them (mail order or otherwise.)  Note that I'm interested in
: books for people who know little or nothing about mac programming in
general
: (but who know something about programming on other platforms.)

I rely on the following pretty heavily:

The Annotated C++ Reference Manual (ARM) Ellis & Stroustrup
Effective C++, Scott Meyers - (Awesome book!)
C++ IOStreams Handbook, Teale
The C Programming Language, K&R
Think Ref, Mac online refernce from Symantec.

Apart from the last one, these are more general C++ references rather
than Mac-specific. I'll leave the Mac stuff to those who actually do
Macs for a living (I play for fun).

Todd Blanchard

---------------------------

>From [e-mail] (Michael Hecht)
Subject: Changing to new toolbox routine names with MacPerl
Date: 25 Sep 1994 06:41:58 GMT
Organization: Vnet Internet Access, Charlotte, NC -  [e-mail]

The new Universal Headers rename many (~135) of the existing toolbox
routines as part of the switch from a trap-based system to a code fragment
system. For example, DisposHandle is now DisposeHandle. Apple suggests
that you change your code to use the new names. Currently, they provide
#defines to map the old name to the new one, but they claimed at the WWDC
that the #defines will go away eventually.

Those of you with MPW can use its canon tool to change the toolbox
routines in all your source code easily. Those of you (like me) without
MPW or canon can do the job using the MacPerl scripts I wrote.

The first script searches the Universal Headers for #defines that look
like old-->new name mappings. I included it for your edification--you
don't need to actually run it. The second script applies the changes (read
from the end of the script) to a group of .c files. Someone could probably
turn this one into a MacPerl droplet if they were so inclined.

Anyway, here they are.
--Michael

============= begin "mkcanon.pl"
# This is the directory where the Universal Headers live on my Mac
$syshdir = 'Wynonna:Development:Symantec C++ for Macintosh:Mac
#includes:Universal Headers:';

# Get a list of all Universal Header files
opendir( SYSHDIR, $syshdir ) || die;
@sysh = grep( /\.h$/, readdir( SYSHDIR ));
closedir( SYSHDIR );

# For each header file
foreach $sysh ( @sysh ) {

   # Read the header file
   open( SYSH, "<$syshdir$sysh" ) || die;
   while( <SYSH> ) {

      # Look for #defines with parameters
      next unless /^#define \w+\(/;

      # Read in multiline #defines
      $_ = $` . <SYSH> while /\\\n$/;

      # Look for #defines that simply rename a function call
      next unless /^#define (\w+)(\([^)]*\)) (\w+)\2/;

      # Get old & new names
      ( $old, $new ) = ( $1, $3 );

      # The "IU" routines are confused in <TextUtils.h>    Apple?
      ( $new, $old ) = ( $old, $new ) if $new =~ /^IU/i;

      print "$old --> $new\n";
   }
   close( SYSH );
}
============= end "mkcanon.pl"

============= begin "canon.pl"
# This is the directory of source code to be changed
$projdir = 'Wynonna:MyProject:';

# This is the directory that the changed files will be written to
$outdir  = 'Wynonna:MyProject Out:';

# Unbuffer STDOUT
$| = 1;

# Initialize substitution command string
$s = "";
$npairs = 0;

print "\nReading mapping pairs... ";

# Read mapping pairs
while( <DATA> ) {

   # Split up this mapping pair
   chop;
   ( $old, $new ) = split( / --> / );

   # Append substitution command to string
   $s .= "\$n = s/\\b$old\\b/$new/g; \$canon{ '$_' } += \$n if \$n;\n";

   # Count pairs
   $npairs++;
}

print "$npairs\n";

# Uncomment next line to see what kind of code we're generating
#print $s;

# Get a list of all the source files in the project directory
opendir( PROJDIR, $projdir ) || die;
@proj = grep( /\.cp{0,2}$/, readdir( PROJDIR ));
closedir( PROJDIR );

# Read entire file at once rather than line-by-line
undef $/;
$* = 1;

# Go through the list of files
foreach $proj ( @proj ) {

   # Read this file
   open( PROJ, "<$projdir$proj" ) || die;
   ( $fcreator, $ftype ) = &MacPerl'GetFileInfo( "$projdir$proj" );
   $_ = <PROJ>;
   close( PROJ );

   # Reset our count of substitutions made, and perform all substitutions
   undef %canon;
   eval $s;

   # Continue if no changes were made
   next unless %canon;

   # Log the changes
   print "\n$proj:\n";
   foreach $change ( sort keys %canon ) {
      print "$change: $canon{$change}\n";
   }

   # Uncomment next line to skip writing the changed file
#   next;

   # Write the file
   open( PROJ, ">$outdir$proj" ) || die;
   &MacPerl'SetFileInfo( $fcreator, $ftype, "$outdir$proj" );
   print PROJ;
   close( PROJ );
}

__END__
SetCTitle --> SetControlTitle
GetCTitle --> GetControlTitle
UpdtControl --> UpdateControls
SetCtlValue --> SetControlValue
GetCtlValue --> GetControlValue
SetCtlMin --> SetControlMinimum
GetCtlMin --> GetControlMinimum
SetCtlMax --> SetControlMaximum
GetCtlMax --> GetControlMaximum
SetCRefCon --> SetControlReference
GetCRefCon --> GetControlReference
SetCtlAction --> SetControlAction
GetCtlAction --> GetControlAction
SetCtlColor --> SetControlColor
GetAuxCtl --> GetAuxiliaryControlRecord
GetCVariant --> GetControlVariant
getctitle --> getcontroltitle
setctitle --> setcontroltitle
DisposDialog --> DisposeDialog
UpdtDialog --> UpdateDialog
GetDItem --> GetDialogItem
SetDItem --> SetDialogItem
HideDItem --> HideDialogItem
ShowDItem --> ShowDialogItem
SelIText --> SelectDialogItemText
GetIText --> GetDialogItemText
SetIText --> SetDialogItemText
FindDItem --> FindDialogItem
GetAlrtStage --> GetAlertStage
ResetAlrtStage --> ResetAlertStage
DlgCut --> DialogCut
DlgPaste --> DialogPaste
DlgCopy --> DialogCopy
DlgDelete --> DialogDelete
SetDAFont --> SetDialogFont
getitext --> getdialogitemtext
setitext --> setdialogitemtext
findditem --> finddialogitem
KeyTrans --> KeyTranslate
LDoDraw --> LSetDrawingMode
LFind --> LGetCellDataLocation
lfind --> lgetcelldatalocation
ApplicZone --> ApplicationZone
MFTempNewHandle --> TempNewHandle
MFMaxMem --> TempMaxMem
MFFreeMem --> TempFreeMem
MFTempHLock --> TempHLock
MFTempHUnlock --> TempHUnlock
MFTempDisposHandle --> TempDisposeHandle
MFTopMem --> TempTopMem
ResrvMem --> ReserveMem
DisposPtr --> DisposePtr
DisposHandle --> DisposeHandle
ReallocHandle --> ReallocateHandle
AddResMenu --> AppendResMenu
InsMenuItem --> InsertMenuItem
DelMenuItem --> DeleteMenuItem
SetItem --> SetMenuItemText
GetItem --> GetMenuItemText
GetMHandle --> GetMenuHandle
DelMCEntries --> DeleteMCEntries
DispMCInfo --> DisposeMCInfo
addresmenu --> appendresmenu
getitem --> getmenuitemtext
setitem --> setmenuitemtext
insmenuitem --> insertmenuitem
OSAComponentFunctionInline --> ComponentCallNow
LongDate2Secs --> LongDateToSeconds
LongSecs2Date --> LongSecondsToDate
IUMetric --> IsMetric
Date2Secs --> DateToSeconds
Secs2Date --> SecondsToDate
DisposPictInfo --> DisposePictInfo
DisposPixMap --> DisposePixMap
DisposPixPat --> DisposePixPat
DisposCTable --> DisposeCTable
DisposCCursor --> DisposeCCursor
DisposCIcon --> DisposeCIcon
DisposGDevice --> DisposeGDevice
NDrawJust --> DrawJustified
NMeasureJust --> MeasureJustified
NPortionText --> PortionLine
SizeResource --> GetResourceSizeOnDisk
MaxSizeRsrc --> GetMaxResourceSize
RmveResource --> RemoveResource
SetSysJust --> SetSysDirection
GetSysJust --> GetSysDirection
Font2Script --> FontToScript
GetEnvirons --> GetScriptManagerVariable
SetEnvirons --> SetScriptManagerVariable
IUGetIntl --> GetIntlResource
IUSetIntl --> SetIntlResource
IUClearCache --> ClearIntlResourceCache
IUGetItlTable --> GetIntlResourceTable
TESetJust --> TESetAlignment
TextBox --> TETextBox
TEStylNew --> TEStyleNew
SetStylHandle --> TESetStyleHandle
GetStylHandle --> TEGetStyleHandle
GetStyleHandle --> TEGetStyleHandle
TEStylPaste --> TEStylePaste
GetStylScrap --> TEGetStyleScrapHandle
GetStyleScrap --> TEGetStyleScrapHandle
SetStylScrap --> TEUseStyleScrap
SetStyleScrap --> TEUseStyleScrap
TEStylInsert --> TEStyleInsert
TESetScrapLen --> TESetScrapLength
TEGetScrapLen --> TEGetScrapLength
SetClikLoop --> TESetClickLoop
SetWordBreak --> TESetWordBreak
IULDateString --> LongDateString
iuldatestring --> longdatestring
IULDateString --> LongTimeString
iultimestring --> longtimestring
String2Date --> StringToDate
String2Time --> StringToTime
UprString --> UpperString
uprstring --> upperstring
IUCompPString --> CompareString
iucomppstring --> comparestring
IUMagPString --> CompareText
IUMagIDPString --> IdenticalText
IUEqualPString --> IdenticalString
iuequalpstring --> identicalstring
IULangOrder --> LanguageOrder
IUTextOrder --> TextOrder
IUStringOrder --> StringOrder
Str2Format --> StringToFormatRec
Format2Str --> FormatRecToString
FormatX2Str --> ExtendedToString
FormatStr2X --> StringToExtended
IUDatePString --> DateString
iudatepstring --> datestring
IUTimePString --> TimeString
iutimepstring --> timestring
============= end "canon.pl"

+++++++++++++++++++++++++++

>From [e-mail] (Matthias Neeracher)
Date: 25 Sep 1994 12:26:08 GMT
Organization: Swiss Federal Institute of Technology (ETHZ)

[e-mail] (Michael Hecht) writes:
>Those of you with MPW can use its canon tool to change the toolbox
>routines in all your source code easily. Those of you (like me) without
>MPW or canon can do the job using the MacPerl scripts I wrote.

K001. Hope you don't mind me borrowing these for my MacPerl hall of fame?

>============= begin "mkcanon.pl"
># This is the directory where the Universal Headers live on my Mac
>$syshdir = 'Wynonna:Development:Symantec C++ for Macintosh:Mac
>#includes:Universal Headers:';

For those taking the script out of this article & try to run it:
The above two lines are in fact one long word wrapped line.

Matthias

- ---
Matthias Neeracher <[e-mail]>
http://err.ethz.ch/members/neeri.html
  "And that's why I am going to turn this world upside down, and make
   of it a fire so *bright* that someone real will notice"
                                -- Vernor Vinge, _Tatja Grimm's World_

---------------------------

>From [e-mail] (Darren Giles)
Subject: Cleanest way to turn AppleTalk on-off
Date: Thu, 15 Sep 1994 08:04:28 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)


What is the cleanest way to turn AppleTalk on & off?  I've used MPPOpen and
MPPClose with some success in the past, but it's no longer in the universal
headers.  There's a mention of using OpenDriver in IM, but I'm a little
leery of using it without more info than given.

Basically, what I'm trying to do is simulate clicking on the "AppleTalk
on/off"
buttons in the Chooser.  Has anyone done this?

- Darren

<Std. Disclaimer>  I know this is not something that should "normally" be
done.
I'm working on an embedded application, where the user will never even see
the
screen... so "normal" doesn't seem to apply.

+++++++++++++++++++++++++++

>From [e-mail] (Darren Giles)
Date: Mon, 26 Sep 1994 02:27:06 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <[e-mail]>, I asked:
>
>What is the cleanest way to turn AppleTalk on & off?
>
>Basically, what I'm trying to do is simulate clicking on the "AppleTalk
on/off"
>buttons in the Chooser.  Has anyone done this?

I got answers from several people, request for the info from several others.
Here's the code I'm now using, which works great:

//////////////////////////////////////////////////////////////////////////////
//
//    Must reboot after an off -> on transition for change to take effect
//////////////////////////////////////////////////////////////////////////////
//
void cdev_atalk_on (void) {
    LMSetSPConfig (useATalk);
}


//////////////////////////////////////////////////////////////////////////////
//
void cdev_atalk_off (void) {
    LMSetSPConfig (useAsync);
}




---------------------------

>From [e-mail] (Dick Startz)
Subject: Dialog Edit text> 256 characters
Date: Thu, 22 Sep 1994 08:45:43 +0800
Organization: University of Washington

I have a desparate need to display very long edit text items in dialogs.
Can anyone suggest a kludge to let me do this? BTW, sometimes I have more
than one per dialog.

Thanks to all.
-Dick Startz

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Thu, 22 Sep 1994 15:47:54 -0500
Organization: One Step Beyond

[e-mail] (Dick Startz) wrote:

) I have a desparate need to display very long edit text items in dialogs.
) Can anyone suggest a kludge to let me do this? BTW, sometimes I have
) more than one per dialog.

I just answered this in another post yesterday (complete with untested
sample code).  I'm afraid I can't remember the subject line, but it was
similar to yours.

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Fri, 23 Sep 1994 10:39:58 +0800
Organization: NCRPDA, Curtin University

In article <startz-2209940845440001@128.95.72.95>, [e-mail]
(Dick Startz) wrote:

>I have a desparate need to display very long edit text items in dialogs.
>Can anyone suggest a kludge to let me do this? BTW, sometimes I have more
>than one per dialog.

Just write a dialog user item proc, and use TextBox (or better yet, use
NeoTextBox as described in develop a few issues back (16?)).
   Peter.
--
Peter N Lewis <[e-mail]> - Macintosh TCP fingerpainter
FTP my programs from redback.cs.uwa.edu.au:Others/PeterLewis/ or
amug.org:pub/peterlewis/ or nic.switch.ch:software/mac/peterlewis/

+++++++++++++++++++++++++++

>From [e-mail] (Lee Fyock)
Date: Fri, 23 Sep 1994 10:23:59 -0400
Organization: The MathWorks, Inc.

In article <[e-mail]>,
[e-mail] (Peter N Lewis) wrote:

> In article <startz-2209940845440001@128.95.72.95>, [e-mail]
> (Dick Startz) wrote:
>
> >I have a desparate need to display very long edit text items in dialogs.
> >Can anyone suggest a kludge to let me do this? BTW, sometimes I have more
> >than one per dialog.
>
> Just write a dialog user item proc, and use TextBox (or better yet, use
> NeoTextBox as described in develop a few issues back (16?)).

This is too tough.  Just get the TEHandle associated with the dialog item,
and set the hText to whatever you'd like.  The Dialog Manager does fine at
displaying the item and editing it.

To set it up, do like so:

   dlogPtr = GetNewDialog(DISPLAY_DLOG, nil, (WindowPtr) -1);
   SetPort(dlogPtr);

   GetDItem(dlogPtr,TEXT_ITEM,&iType,&iHandle,&iRect);

   teH = ((DialogPeek) dlogPtr)->textH;

   // textH contains the >255 character text to put into the dialog
   SetHandleSize((**teH).hText, 0);
   HLock(textH);
   err = HandAndHand(textH, (**teH).hText);
   HUnlock(textH);
   TECalText(teH);

The "GetDItem" is necessary to get the Dialog Manager to actually load the
dialog and set it up...  You may need to add some stuff for more than one
text item in the dialog, since the dialog has only one TextEdit record
that is switched between the text items.

Getting the data back out is similar and is left as an exercise to the
reader.

Have fun!
Lee


- ------------------------------------------------------------------
Lee Fyock                                    "I think I would remain
[e-mail]                                perfectly still."

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Sat, 24 Sep 1994 10:19:35 -0800
Organization: Integer Poet Software

In article <startz-2209940845440001@128.95.72.95>, [e-mail]
(Dick Startz) wrote:

> I have a desparate need to display very long edit text items in dialogs.
> Can anyone suggest a kludge to let me do this? BTW, sometimes I have more
> than one per dialog.

My understanding is that although the system calls which access the
editText items take Pascal strings and thus are limited to 255 characters,
it's possible to have larger pieces of text in an editText item. You just
can't get that text out using the standard routines. You might want to
reverse-engineer just exactly what kind of handle is returned to you by
GetDItem. It may be a text handle and it may be a TE handle. Let us know
what you discover.

--

 Pete Gontier // CTO, Integer Poet Software // [e-mail]

 "Anything the Windows gang hates this much can't be all bad."
   -- Andrew Gore <[e-mail]>, on OpenDoc, MacWEEK 9/19/94

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Mon, 26 Sep 1994 09:02:59 -0800
Organization: Integer Poet Software

In article <364jlo$[e-mail]>, [e-mail] (Stefan
Kurth) wrote:

> In article <[e-mail]>,
> [e-mail] (Pete Gontier) wrote:
>
> > You might want to reverse-engineer just exactly what kind of handle is
> > returned to you by GetDItem. It may be a text handle and it may be a TE
> > handle. Let us know what you discover.
>
> Think Reference says it's the hText field of a TE handle, and that
> sounds reasonable to me, because there is only one TE handle in a
> dialog, even if there are several text fields.

However, if you call 'GetDItem' for an editText which is not active (does
not have the insertion point), the handle cannot be directly from the
'hText' field. Perhaps it's
the-handle-which-might-be-in-the-'htext'-field. :-)

Anyway, it would be interesting if this sort of thing is an
Apple-documented behavior. I can't remember ever seeing documentation to
this effect; your THINK Reference, er, reference is news to me.

I'm not saying it's a bad idea to rely on this, but it would be nice to
see an Apple sanction, just to make it official.

--

 Pete Gontier // CTO, Integer Poet Software // [e-mail]

 "One of (Misty's) recent paintings, 'Interring the Terrier', 1993, which
 appears to show a small headless dog being stuffed inside a red armchair by
 two frogs and a sardine, sold at auction for $21,000 -- a record price..."
                           -- Busch and Silver, 'Why Cats Paint', p55

---------------------------

>From [e-mail] (Craig Kloeden)
Subject: Fast zeroing on PPC
Date: Sun, 18 Sep 1994 00:56:26 +0930
Organization: University of Adelaide

I have the following piece of code:

- -

Byte  plane[maxX][maxY];

for (i=0;i<maxX;i++)
  for (j=0;j<maxY;j++)
    plane[i][j] = 0;

- -

Believe it or not, this is a bottleneck in my program.
I need to make this as fast as possible on the PPC.

Any advice would be appreciated.

Craig

--
Craig Kloeden                 E-mail: [e-mail]
Road Accident Research Unit   Phone : [phone]
The University of Adelaide    Fax   : [phone]
Australia                     Disclaimer: Not this little black duck!

+++++++++++++++++++++++++++

>From [e-mail]
Date: 17 Sep 94 11:06:28 MST
Organization: (none)

In article <[e-mail]>,
[e-mail] (Craig Kloeden) writes:
> I have the following piece of code:
>
> ---
>
> Byte  plane[maxX][maxY];
>
> for (i=0;i<maxX;i++)
>   for (j=0;j<maxY;j++)
>     plane[i][j] = 0;
>
> ---
>
> Believe it or not, this is a bottleneck in my program.
> I need to make this as fast as possible on the PPC.
>
> Any advice would be appreciated.
>

Please note that I've cross-posted this to c.s.powerpc, (which is where it
belongs, IMHO).

Several things that you can do here:

First, understand that you are dealing with a cached memory, where x values
can
fit in cache lines, and you want to deal with things one cache line at a
time.
Make the x loop your inner loop.

Second, recognize that you are dealing with 1 byte numbers when you could
easily
be dealing with 4-byte numbers (or 8 if you are doing this directly to video
where the video bus latency makes up for the slow speed of doing floating
point
load stores). Redo your loop as manipulating longs, and it will go much
faster.

Third, remember that the MPC601 chip "pipelines" loads and stores, so if you
"unroll/unwrap" your inner loop so that you are performing [at least] 4
loads/stores each time through, you will see a tremendous speedup.

Finally, if you have access to the PPCAsm, you can directly zero out this
memory (if it all fits in the L1 cache) by simply using the assembly language
instruction that zeros the cache rather than loading it from memory and THEN
zeroing it. This would give you a HUGE speedup from what I understand. I
don't
have my MPC601 user's manual handy, and this isn't something that I really
know
how to do, so if some kind soul that DOES know how to do this would go into
greater detail for him (and me)?

If you don't have the PPCAsm, maybe we could compose this routine on-line for
you, and I or somebody else could assemble it and either post it here in .hqx
format or just e-mail it to you... That way, you could just link it to your
program as a library routine...


Lawson

+++++++++++++++++++++++++++

>From [e-mail] (Bob Boonstra)
Date: Sat, 17 Sep 1994 18:22:30 -0400
Organization: MITRE Corp.

In article <[e-mail]>,
[e-mail] (Craig Kloeden) wrote:

> I have the following piece of code:
> Byte  plane[maxX][maxY];
> for (i=0;i<maxX;i++)
>   for (j=0;j<maxY;j++)
>     plane[i][j] = 0;
>
> Believe it or not, this is a bottleneck in my program.
> I need to make this as fast as possible on the PPC.
> Any advice would be appreciated.

Others can probably do better, but you can get a significant improvement
by writing in units larger than bytes and by loop unrolling. For example,
the following code is more than 4 times faster than the original:

register long double *p,*q;
register long double zero=0;

p = (long double *)plane;
q = p + maxX*maxY/sizeof(long double);
/* This assumes maxY is a multiple of long double in size */
/* If not, add a cleanup loop at the end. */

while (p<q) {
  *p = zero; *(p+1)=zero; *(p+2)=zero; *(p+3)=zero;
  p += 4;
}

This generates the following rather efficient PPC code using
Metrowerks CW4 (with maxX=64 and maxY=256):

00000000: 80620000  lwz      r3,@41(RTOC)
00000004: 80820000  lwz      r4,plane(RTOC)
00000008: C8030000  lfd      fp0,0(r3)
0000000C: 38044000  addi     r0,r4,16384
00000010: 42800018  bc       ALWAYS,cr0_LT,*+24      ; $00000028
00000014: D8040000  stfd     fp0,0(r4)
00000018: D8040008  stfd     fp0,8(r4)
0000001C: D8040010  stfd     fp0,16(r4)
00000020: D8040018  stfd     fp0,24(r4)
00000024: 38840020  addi     r4,r4,32
00000028: 7C040040  cmplw    r4,r0
0000002C: 4180FFE8  blt      *-24                    ; $00000014
00000030: 4E800020  blr

For further info on PPC optimization, I suggest you look at the article
by Dave Evans in develop 18, the article by Dave Radcliffe in develop
16, and a collection of articles in recent issues of MacTech by Richard
Clark.
--
-- Bob Boonstra
-- [e-mail]
-- My opinion, not my employer's

+++++++++++++++++++++++++++

>From [e-mail] (The Weasel)
Date: 18 Sep 1994 18:54:03 GMT
Organization: Computer Science Department, Stanford University.

>In article <[e-mail]>,
>[e-mail] (Craig Kloeden) wrote:
>
>> I have the following piece of code:
>> Byte  plane[maxX][maxY];
>> for (i=0;i<maxX;i++)
>>   for (j=0;j<maxY;j++)
>>     plane[i][j] = 0;
>>
>> Believe it or not, this is a bottleneck in my program.
>> I need to make this as fast as possible on the PPC.
>> Any advice would be appreciated.

[ Good suggestions deleted ]

Another things you might try is to allocate your memory in a single
continous block and running through it linearly. The array references
that you have above is sort of equivilant to:

    plane[i * kMaxY + j] = ...

Additionally, this may not be true based on your snippet, but if you
are allocating the memory dynamically then allocating a single block
is definitely cheaper and easier on the cache.

Peter


+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Sun, 18 Sep 1994 14:38:12 +1200 (NZST)
Organization: (none)

[e-mail] (Craig Kloeden) writes:
> I have the following piece of code:
>
> ---
>
> Byte  plane[maxX][maxY];
>
> for (i=0;i<maxX;i++)
>   for (j=0;j<maxY;j++)
>     plane[i][j] = 0;
>
> ---
>
> Believe it or not, this is a bottleneck in my program.
> I need to make this as fast as possible on the PPC.
>
> Any advice would be appreciated.

The quality of code generation doesn't matter much here -- it's all
in how efficiently you bash the memory subsystem.

The problem with the straight C code is that the processor has to read
the old data from RAM, then you zero it, then you write it back.  It's
twice as fast if you only have to write the data out.

This is exactly what the PPC "dcbz" instruction (Data Cache Block Zero)
does -- it zeros 32 bytes of memory without first reading it from external
RAM.  i.e. it totally ignores the previous contents.

This is useful no matter what you want to write into the memory, but it
you happen to *want* zeros, then you don't need to do anything else.

Here's a little PPC assembly routine that makes this instruction
available to you in C, and an XCOFF object file that you can use from
botht eh MPW and CodeWarrior compilers:

- -------------------------------
; void Zero32Bytes(void *p)
; function that zeros a 32 byte range of memory using dcbz

   export Zero32Bytes[DS]
   export .Zero32Bytes[PR]

   toc
   tc Zero32Bytes[TC], Zero32Bytes[DS]

   csect Zero32Bytes[DS]
   dc.l .Zero32Bytes[PR]
   dc.l TOC[tc0]
   dc.l 0

   csect .Zero32Bytes[PR]
   dcbz r0,r3 ;implicit r0=0
   blr
- -------------------------------
- -------------------------------


Be careful!  This is somewhat of a shotgun!  It zeros not the 32
bytes starting at the pointer, but the 32 bytes *around* the
pointer -- from p&~31 to p|31.  Make sure you don't want anything
that's already there next to your array!

*IF* your array is aligned to a 32-byte boundary AND each row is
a multiple of 32 bytes long, then all you need to use this is
(in C -- in C++ you'll need 'extern "C"'):

- -------------------------------
extern void Zero32Bytes(void *p);

Byte  plane[maxX][maxY];

for (i=0;i<maxX;i++)
  for (j=0;j<maxY;j+=32)
    Zero32Bytes(&plane[i][j]);
- -------------------------------

Hope this helps.

Oh, yeah, if you try to use this on non-cachable memory (such as the
video memory) you'll get an alignment exception trap.

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Al Evans)
Date: 19 Sep 94 13:43:14 GMT
Organization: PowerTools, Austin, Texas

In article <[e-mail]>
[e-mail] (Craig Kloeden) writes:

>I have the following piece of code:

>---
>
>Byte  plane[maxX][maxY];
>
>for (i=0;i<maxX;i++)
>  for (j=0;j<maxY;j++)
>    plane[i][j] = 0;
>
>---

>Believe it or not, this is a bottleneck in my program.
>I need to make this as fast as possible on the PPC.

Here's an answer I haven't seen yet.

If you've got the memory to spare, you can initialize one copy of
your plane array, then use

    BlockMoveData(inittedMaster, plane, maxX * maxY);

To rapidly initialize the "real" plane. If plane is particularly large,
it will be hard to beat this technique for speed. And since BlockMove()
is a ROM routine, you can be certain it's optimized for each Mac model.

                    --Al Evans--
--
Al Evans        |   Graphic Elements: A new standard for
________________________|__ high-performance interactive Macintosh graphics.
[e-mail] |  Available from mac.archive.umich.edu
- -------------------------|
/mac/development/libraries/graphicelements2.sit.hqx

+++++++++++++++++++++++++++

>From Darrin Cardani <[e-mail]>
Date: Mon, 19 Sep 1994 14:42:50 GMT
Organization: AT&T Global Information Solutions, Atlanta

>In article <35i2cb$[e-mail]> The Weasel writes:
>>In article <[e-mail]>,
>>[e-mail] (Craig Kloeden) wrote:
>>
>>> I have the following piece of code:
>>> Byte  plane[maxX][maxY];
>>> for (i=0;i<maxX;i++)
>>>   for (j=0;j<maxY;j++)
>>>     plane[i][j] = 0;
>>>
>>> Believe it or not, this is a bottleneck in my program.
>>> I need to make this as fast as possible on the PPC.
>>> Any advice would be appreciated.
>
>[ Good suggestions deleted ]
>
>Another things you might try is to allocate your memory in a single
>continous block and running through it linearly. The array references
>that you have above is sort of equivilant to:
>
>    plane[i * kMaxY + j] = ...

What about

Ptr plane;

plane = NewPtrClear (maxX*maxY);

Or is NewPtrClear not very efficient?

Darrin







+++++++++++++++++++++++++++

>From [e-mail] (christopher weare)
Date: 19 Sep 1994 10:47:33 -0700
Organization: University of California, Riverside

<fast zeroing stuff deleted>

You might want to try unrolling your loops abit:

long    numFloats, i;
float    *pointer,*temp;

    pointer = (float *)NewPointer(sizeof(float)*numFloats);
    temp = pointer;

    for(i=0;i<numFloats;i+=4){
        *(temp) = 0.0;
        *(temp+1) = 0.0;
        *(temp+2) = 0.0;
        *(temp+3) = 0.0;

        temp += 4;
    }

...

ofcourse this assumes that numFloats is divisable by for.  If not just clean
up at the end of the main loop.  Notice that this requires only addition in
calculating offsets and should keep the pipelines busy.  Experiment with the
amount of unrolling.  As always, your milage may vary.

Chris
[e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Dale Semchishen [4597])
Date: Mon, 19 Sep 1994 19:24:55 GMT
Organization: Glenayre Electronics Ltd.

In article [e-mail], [e-mail] (The Weasel)
writes:
>>In article <[e-mail]>,
>>[e-mail] (Craig Kloeden) wrote:
>>
>>> I have the following piece of code:
>>> Byte  plane[maxX][maxY];
>>> for (i=0;i<maxX;i++)
>>>   for (j=0;j<maxY;j++)
>>>     plane[i][j] = 0;
>>>
>>> Believe it or not, this is a bottleneck in my program.
>>> I need to make this as fast as possible on the PPC.
>>> Any advice would be appreciated.

You write a function that zeros a generic buffer as follows:

    - two parameters (buffer_pointer and number_of_bytes)
    - calculate how many longs are in buffer by shifting number_of_bytes
      right twice
    - clear the calculated number of longs and then the remaining bytes

If you are compiling your source code for PPC and the Plain Jane 68000,
then your function must make sure it does not write a long to an odd address.

- -
Dale Semchishen           | [e-mail]
Glenayre Electronics Ltd  | [phone]
Vancouver, BC, CANADA     |



+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Tue, 20 Sep 1994 02:30:52 GMT
Organization: Adobe Systems Incorporated

Al Evans writes
> If you've got the memory to spare, you can initialize one copy of
> your plane array, then use
>     BlockMoveData(inittedMaster, plane, maxX * maxY);
> To rapidly initialize the "real" plane. If plane is particularly large,
> it will be hard to beat this technique for speed. And since BlockMove()
> is a ROM routine, you can be certain it's optimized for each Mac model.

This is a bad answer as it takes approximately twice the memory bandwidth.
(And introduces another read latency into a conceptually write only
operation.) To put it mildly, there is a reason you haven't this mentioned
yet.

In theory, the right solution is "memset(plane, 0, sizeof(plane));" but
Apple blew it big time in implementing memset. A really good PowerPC
implementation of this operation might try to use the data cache block zero
instruction, though  it cannot be used on uncached memory and you p[retty
much have to know the cache block size to implement the code. (In other
words, doing it portably requires dynamic code generation.)

For this application, an unrolled loop that writes longs will probably work
fine. Writing floating-point values on the MPC601 is dubious as you can only
get in one floating-point store per 3 cycles. If you're going to uncached
memory that is probably the right thing. Otherwise not.
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
 Please do not change color while I am talking to you -- MC 900 Ft Jesus.

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Tue, 20 Sep 1994 02:30:40 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Bruce Hoult <[e-mail]> wrote:
>[e-mail] (Craig Kloeden) writes:
>> I have the following piece of code:
>>
>> ---
>>
>> Byte  plane[maxX][maxY];
>>
>> for (i=0;i<maxX;i++)
>>   for (j=0;j<maxY;j++)
>>     plane[i][j] = 0;
>>
>> ---
>>
>> Believe it or not, this is a bottleneck in my program.
>> I need to make this as fast as possible on the PPC.
>>
>> Any advice would be appreciated.
>
>The quality of code generation doesn't matter much here -- it's all
>in how efficiently you bash the memory subsystem.

Actually, the quality of code generation is quite important. Compilers
can do all sorts of tricks to speed up loops like the above. Things
that are often done manually, such as loop unrolling, pointer
arithmetic, common subexpression elimination, etc. can all be handled
by the compiler. And the compiler may be better suited to make decisions
on pipelining instructions for a RISC processor.

What the original poster needs is to zero a block of memory of maxY by
maxX bytes. The simple call memset(p,0,n) is almost always sufficient
and it's portable. Assuming the compiler's optimizer or implementation
of memset is pathetic, he can hand-code all sorts of optimizations,
most of which have already been suggested.  One other way to unroll a
loop is to use a fancy (or obscure, take your pick) switch statement;
most C texts have it as an exercise in "what does this do", but I
don't know if it really is any faster than a more obvious loop
unrolling. The use of a dedicated processor instruction (as suggested
by Bruce) along with the other optimizations should result in a
memory-zeroing routine that is as fast as can be made.

Further optimizations would have to examine the need for the zeroed
memory.

Does the memory have to be zeroed, or is it just being filled up with
data later on that don't need to be zeroed initially?

Is the array being used to represent a data structure that would be
better represented in some other form?

Is the algorithm written in such a way that the memory zeroing code is
being called more than may be necessary?

Could the memory be zeroed in small chunks over time, rather than all
at once? You could spawn a thread to do the zeroing, and run it in the
background while the user is figuring out which buttons to click. By
the time the user is ready to do something, the memory is zeroed, and
the user will notice no delay. If the user is real speedy, you can
always wait for the thread to complete before proceeding. (This is an
approximation of parallelization, where a second processor and
instruction set are simulated via a thread.)




--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Tue, 20 Sep 1994 16:10:12 +1200 (NZST)
Organization: (none)

[e-mail] writes:
> > Byte  plane[maxX][maxY];
> >
> > for (i=0;i<maxX;i++)
> >   for (j=0;j<maxY;j++)
> >     plane[i][j] = 0;
>
> Finally, if you have access to the PPCAsm, you can directly zero out this
> memory (if it all fits in the L1 cache) by simply using the assembly
language
> instruction that zeros the cache rather than loading it from memory and
THEN
> zeroing it. This would give you a HUGE speedup from what I understand. I
don't
> have my MPC601 user's manual handy, and this isn't something that I really
know
> how to do, so if some kind soul that DOES know how to do this would go into
> greater detail for him (and me)?
>
> If you don't have the PPCAsm, maybe we could compose this routine on-line
for
> you, and I or somebody else could assemble it and either post it here in
.hqx
> format or just e-mail it to you... That way, you could just link it to your
> program as a library routine...

Already done :-)

+++++++++++++++++++++++++++

>From [e-mail] (Craig Kloeden)
Date: Tue, 20 Sep 1994 22:55:44 +0930
Organization: University of Adelaide

In article <[e-mail]>, [e-mail]
(Bruce Hoult) wrote:
- > Byte  plane[maxX][maxY];
- >
- > for (i=0;i<maxX;i++)
- >   for (j=0;j<maxY;j++)
- >     plane[i][j] = 0;
- > Believe it or not, this is a bottleneck in my program.
- > I need to make this as fast as possible on the PPC.
- >
- > Any advice would be appreciated.
-
- The quality of code generation doesn't matter much here -- it's all
- in how efficiently you bash the memory subsystem.
-
- The problem with the straight C code is that the processor has to read
- the old data from RAM, then you zero it, then you write it back.  It's
-
- This is exactly what the PPC "dcbz" instruction (Data Cache Block Zero)
- does -- it zeros 32 bytes of memory without first reading it from external
- RAM.  i.e. it totally ignores the previous contents.
-
- This is useful no matter what you want to write into the memory, but it
- you happen to *want* zeros, then you don't need to do anything else.
-
- Here's a little PPC assembly routine that makes this instruction
- available to you in C, and an XCOFF object file that you can use from
- botht eh MPW and CodeWarrior compilers:

Many many thanks. This is exactly what i needed.
Check out ftp://raru.adelaide.edu.au/rotater/
if you want to see the final program.

thanks again

Craig

--
Craig Kloeden                 E-mail: [e-mail]
Road Accident Research Unit   Phone : [phone]
The University of Adelaide    Fax   : [phone]
Australia                     Disclaimer: Not this little black duck!

+++++++++++++++++++++++++++

>From [e-mail] (Gary G. McGrath)
Date: Tue, 20 Sep 1994 20:25:54 GMT
Organization: University of California, Department of Physics


|> If you've got the memory to spare, you can initialize one copy of
|> your plane array, then use
|>
|>     BlockMoveData(inittedMaster, plane, maxX * maxY);
|>
|> To rapidly initialize the "real" plane. If plane is particularly large,
|> it will be hard to beat this technique for speed. And since BlockMove()
|> is a ROM routine, you can be certain it's optimized for each Mac model.

--

Maybe some apple folks can better tell us the validity of this last sentence.
Can
we be sure that BlockMoveData will be optimized for whatever platform it is
on?  I
seem to remember a MacTech article on 040 assembly optimization of
BlockMoveData
where he got something like a factor 2+ on small to medium size routines
because of
less overhead.  I would say that is consistent with my experience.

                    Sincerely,
                    Gary McGrath

+---------------------+--------------------------------------------
| _ O _    O      O   | Gary McGrath                               \
|  \|/   _/|\_   |||  | Stanford Linear Accelerator Center, MS-95   \
|   |      |      |   | PO Box 4349                                  \
| _/ \_  _/ \_  _/ \_ | Stanford, CA 94307 |  27887::gary             \
|---------------------|                    |  [e-mail]         \
| Shiny, Happy People | [phone]     |  [e-mail] \
+---------------------+--------------------+------------------------------

* My opinions do not represent those of Stanford University,
the University of California, or the D.O.E.

+++++++++++++++++++++++++++

>From [e-mail]
Date: 21 Sep 94 08:39:09 MST
Organization: (none)

In article <[e-mail]>, [e-mail] (Bruce
Hoult) writes:
> [e-mail] (Craig Kloeden) writes:
>> I have the following piece of code:
>>
>> ---
>>
>> Byte  plane[maxX][maxY];
>>
>> for (i=0;i<maxX;i++)
>>   for (j=0;j<maxY;j++)
>>     plane[i][j] = 0;
>>
>> ---
>>
>> Believe it or not, this is a bottleneck in my program.
>> I need to make this as fast as possible on the PPC.
>>
>> Any advice would be appreciated.
>
> The quality of code generation doesn't matter much here -- it's all
> in how efficiently you bash the memory subsystem.
>
> The problem with the straight C code is that the processor has to read
> the old data from RAM, then you zero it, then you write it back.  It's
> twice as fast if you only have to write the data out.
>
> This is exactly what the PPC "dcbz" instruction (Data Cache Block Zero)
> does -- it zeros 32 bytes of memory without first reading it from external
> RAM.  i.e. it totally ignores the previous contents.
>
> This is useful no matter what you want to write into the memory, but it
> you happen to *want* zeros, then you don't need to do anything else.
>
> Here's a little PPC assembly routine that makes this instruction
> available to you in C, and an XCOFF object file that you can use from
> botht eh MPW and CodeWarrior compilers:
>
> ---------------------------------
> ; void Zero32Bytes(void *p)
> ; function that zeros a 32 byte range of memory using dcbz
>
>    export Zero32Bytes[DS]
>    export .Zero32Bytes[PR]
>
>    toc
>    tc Zero32Bytes[TC], Zero32Bytes[DS]
>
>    csect Zero32Bytes[DS]
>    dc.l .Zero32Bytes[PR]
>    dc.l TOC[tc0]
>    dc.l 0
>
>    csect .Zero32Bytes[PR]
>    dcbz r0,r3 ;implicit r0=0
>    blr
> ---------------------------------
> (This file must be converted with BinHex 4.0)
> :$eTPFQmc-N*jG'9c,R-ZE`"B3dp'69"6)!%!!!!"L3!!!!#qA!(I!!+USJ#p!!!
> !QJ!!!!X!!!!!,R4PH(3!!!!!!!!!!!!!!!!!!!J!!!"N!!!!!!!!!!!!!!!!!!!
> !)#jNBA4K!!!!!!!!#!!!!!J!!!!3!!!!E!!!!(`!!!!!!!-!!!!!!%"m!"rX6S!
> !)!!!!!!!!!!8!!!!!!!!!!J!!!!)!!!!#4m!!!!!$!!!!!-I!!!!!"3!!!!((`"
> NBf*k,R-!!!!!!!$rrJ`"C`!!!!!!!!!!!!!!!!!!!3!!D`%!!!!!!!!!!!!!%3!
> !!!!!!!"86d-!!!!!!!!!!"3!!J!!D`%!!!!!!!!!!!!!%3m!!!!!!!!!!!!!!!!
> !"!!!!"3!!J!!D`%!!!!%!!!!!!!!%3-!!!!!!!!!!!!!!!!!%!!!!!J!!J!!!J%
> !!!!-!!!!!!!!%3S!!!!!!!!!!!!!!!!!(!!!!!!!!3!!!J%!!!!)!!!!!!!!%3!
> !!!!!!!!!!!!T@Q9bEc-b3RPdCA-!@Q9bEc-b3RPdCA-!,PTPFQmc-N*jG'9c!$e
> c!!!:
> ---------------------------------
>
>
> Be careful!  This is somewhat of a shotgun!  It zeros not the 32
> bytes starting at the pointer, but the 32 bytes *around* the
> pointer -- from p&~31 to p|31.  Make sure you don't want anything
> that's already there next to your array!
>
> *IF* your array is aligned to a 32-byte boundary AND each row is
> a multiple of 32 bytes long, then all you need to use this is
> (in C -- in C++ you'll need 'extern "C"'):
>
> ---------------------------------
> extern void Zero32Bytes(void *p);
>
> Byte  plane[maxX][maxY];
>
> for (i=0;i<maxX;i++)
>   for (j=0;j<maxY;j+=32)
>     Zero32Bytes(&plane[i][j]);
> ---------------------------------
>
> Hope this helps.
>
> Oh, yeah, if you try to use this on non-cachable memory (such as the
> video memory) you'll get an alignment exception trap.
>
> -- Bruce

I notice that you don't bother with the prologue/epilogue stuff. That's
because
it don't use no local memory, and doesn't call any subroutines, right?

I tried to get Tim Olson's more robust zerobyte procedure to work with
PPCAsm,
but I didn't understand his syntax. It looked like it was designed for an
assembler similar to, but not identical with, PPCAsm (the first time I tried
to
assemble it, it had hundreds of errors).

BTW, I think that we should start compiling a list of useful
assembly-language
routines to suppliment the less-than-perfect compilers that the PowerMac has
available. This could be tacked onto the end of Jon's Mac Programming FAQ, or
could (eventually) be kept separate.

The source code, the tool used to assemble it, and binhexed object code could
all be supplied.

Comments?



Lawson

+++++++++++++++++++++++++++

>From [e-mail]
Date: 21 Sep 94 08:40:32 MST
Organization: (none)

In article <[e-mail]>, Darrin Cardani
<[e-mail]> writes:
>>In article <35i2cb$[e-mail]> The Weasel writes:
>>>In article <[e-mail]>,
>>>[e-mail] (Craig Kloeden) wrote:
>>>
>>>> I have the following piece of code:
>>>> Byte  plane[maxX][maxY];
>>>> for (i=0;i<maxX;i++)
>>>>   for (j=0;j<maxY;j++)
>>>>     plane[i][j] = 0;
>>>>
>>>> Believe it or not, this is a bottleneck in my program.
>>>> I need to make this as fast as possible on the PPC.
>>>> Any advice would be appreciated.
>>
>>[ Good suggestions deleted ]
>>
>>Another things you might try is to allocate your memory in a single
>>continous block and running through it linearly. The array references
>>that you have above is sort of equivilant to:
>>
>>    plane[i * kMaxY + j] = ...
>
> What about
>
> Ptr plane;
>
> plane = NewPtrClear (maxX*maxY);
>
> Or is NewPtrClear not very efficient?
>
> Darrin
>

Only works the first time...



Lawson

+++++++++++++++++++++++++++

>From [e-mail] (Ari I Halberstadt)
Date: Thu, 22 Sep 1994 02:43:54 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
 <[e-mail]> wrote:
>BTW, I think that we should start compiling a list of useful
assembly-language
>routines to suppliment the less-than-perfect compilers that the PowerMac has
>available. This could be tacked onto the end of Jon's Mac Programming FAQ,
or
>could (eventually) be kept separate.
>
>The source code, the tool used to assemble it, and binhexed object code
could
>all be supplied.

This is what the newsgroup alt.sources.mac is for. It's still
premature to consider splitting it into alt.sources.mac.ppc, since
most of the traffic seems to be from people unclear on the purpose of
alt.sources.mac. The archive sites should probably add a "dev/src/ppc"
directory; you might suggest this to the info-mac folks and other
major sites. The FAQ could contain a specific pointer to the various
places to find these PPC goodies.
--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail] (Craig Kloeden)
Date: Fri, 23 Sep 1994 09:21:46 +0930
Organization: University of Adelaide

In article <[e-mail]>, [e-mail] (Ari I
Halberstadt) wrote:
> >> Byte  plane[maxX][maxY];
> >>
> >> for (i=0;i<maxX;i++)
> >>   for (j=0;j<maxY;j++)
> >>     plane[i][j] = 0;
> >The quality of code generation doesn't matter much here -- it's all
> >in how efficiently you bash the memory subsystem.
>
> Actually, the quality of code generation is quite important. Compilers
> can do all sorts of tricks to speed up loops like the above. Things
> that are often done manually, such as loop unrolling, pointer
> arithmetic, common subexpression elimination, etc. can all be handled
> by the compiler. And the compiler may be better suited to make decisions
> on pipelining instructions for a RISC processor.
>
> What the original poster needs is to zero a block of memory of maxY by
> maxX bytes. The simple call memset(p,0,n) is almost always sufficient
> and it's portable. Assuming the compiler's optimizer or implementation
> of memset is pathetic, he can hand-code all sorts of optimizations,
> most of which have already been suggested.  One other way to unroll a
> loop is to use a fancy (or obscure, take your pick) switch statement;
> most C texts have it as an exercise in "what does this do", but I
> don't know if it really is any faster than a more obvious loop
> unrolling. The use of a dedicated processor instruction (as suggested
> by Bruce) along with the other optimizations should result in a
> memory-zeroing routine that is as fast as can be made.
>
> Further optimizations would have to examine the need for the zeroed
> memory.
>
> Does the memory have to be zeroed, or is it just being filled up with
> data later on that don't need to be zeroed initially?

It has to be filled to zero.

> Is the array being used to represent a data structure that would be
> better represented in some other form?

Represents the screen. Well actually it is for keeping a record of the
'depth' of the last plotted pixel to that location. (for hidden point
removal in displaying 3d images.

> Is the algorithm written in such a way that the memory zeroing code is
> being called more than may be necessary?

Only once per frame :-)

> Could the memory be zeroed in small chunks over time, rather than all
> at once? You could spawn a thread to do the zeroing, and run it in the
> background while the user is figuring out which buttons to click.

nope. i need it straight away

Here are some rough benchmarks that I ran. (using CW4)

Time      Method
- --      ------
1033      Clearing Individual Bytes
 270      Clearing 1 long at a time
 249      memset()
 226      Clearing 2 longs at a time (unrolled loop)
 213      Clearing 3 longs at a time (unrolled loop)
 204      Clearing 4 longs at a time (unrolled loop)
  55      bzero*

* bzero is an XCOFF written by [e-mail] (Tim Olson)
  posted recently to comp.sys.powerpc
  assumes cacheable memory (i.e. uses DCBZ)
  assumes 32-byte cache block/sector (works on 601, 603, 604)

The rest of my code uses 386 units of time (best case) so all
but the last significantly cuts into my frame rate.
Guess which one i am using :-)

regards and thanks

Craig

ps. the program i am working on with source is at:
ftp://raru.adelaide.edu.au/rotater/

--
Craig Kloeden                 E-mail: [e-mail]
Road Accident Research Unit   Phone : [phone]
The University of Adelaide    Fax   : [phone]
Australia                     Disclaimer: Not this little black duck!

+++++++++++++++++++++++++++

>From [e-mail] (Al Evans)
Date: 23 Sep 94 14:41:45 GMT
Organization: PowerTools, Austin, Texas

In article <[e-mail]> [e-mail] (Zalman Stern)
writes:

>> use
>>     BlockMoveData(inittedMaster, plane, maxX * maxY);
>> To rapidly initialize the "real" plane.

>This is a bad answer as it takes approximately twice the memory bandwidth.
>(And introduces another read latency into a conceptually write only
>operation.) To put it mildly, there is a reason you haven't this mentioned
>yet.

Oops. Obviously, you're right. I can only plead brain-fade, and the
fact that I was thinking of a case where the memory in question had
to be initialized to something more complex than all zeros.

                    --Al Evans--
--
Al Evans        |   Graphic Elements: A new standard for
________________________|__ high-performance interactive Macintosh graphics.
[e-mail] |  Available from mac.archive.umich.edu
- -------------------------|
/mac/development/libraries/graphicelements2.sit.hqx

+++++++++++++++++++++++++++

>From [e-mail] (Brian Lowry)
Date: Fri, 23 Sep 1994 10:38:08 -0800
Organization: Dept. of Chemical Eng., University of Alberta

In article <[e-mail]>,
[e-mail] (Craig Kloeden) wrote:

> Here are some rough benchmarks that I ran. (using CW4)

> Time      Method
> ----      ------
> 1033      Clearing Individual Bytes
>  270      Clearing 1 long at a time
>  249      memset()
>  226      Clearing 2 longs at a time (unrolled loop)
>  213      Clearing 3 longs at a time (unrolled loop)
>  204      Clearing 4 longs at a time (unrolled loop)
>   55      bzero*

> * bzero is an XCOFF written by [e-mail] (Tim Olson)
>   posted recently to comp.sys.powerpc
>   assumes cacheable memory (i.e. uses DCBZ)
>   assumes 32-byte cache block/sector (works on 601, 603, 604)

Did you try something like:
//plane is a 2D array of bytes
//N = (xMax * yMax) / 8;

register double dblZero = +0.0;
register double *doubleP;

for (i=N, doubleP = &plane[maxX][maxY]; i>0; i--)
{  *(--doubleP) = dblZero;}

I believe a double precision zero is a 64bit zero, and that this takes
fewer clock cycles than writing longs (but I could be wrong).  Just
curious how it might compare...

--

Brian Lowry

+++++++++++++++++++++++++++

>From [e-mail]
Date: 23 Sep 94 18:42:15 MST
Organization: (none)

In article <[e-mail]>,
[e-mail] (Brian Lowry) writes:
> In article <[e-mail]>,
> [e-mail] (Craig Kloeden) wrote:
>
>> Here are some rough benchmarks that I ran. (using CW4)
[deleted]
> Did you try something like:
> //plane is a 2D array of bytes
> //N = (xMax * yMax) / 8;
>
> register double dblZero = +0.0;
> register double *doubleP;
>
> for (i=N, doubleP = &plane[maxX][maxY]; i>0; i--)
> {  *(--doubleP) = dblZero;}
>
> I believe a double precision zero is a 64bit zero, and that this takes
> fewer clock cycles than writing longs (but I could be wrong).  Just
> curious how it might compare...
>

Come on Brian, even *I* know that 8-byte floating-point writes take 3 cycles
while the 4-byte store takes 1 cycle (allowing for pipelining, etc -best
case).

The only time that the double store is better is on non-cached memory like
VRAM, where the bus interface is your biggest problem.

Your scheme is good for zeroing video.


(Gorsh! I almost sound like a know what I'm talking about... I hope I didn't
mangle what everyone else has told me too badly)


Lawson

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Sun, 25 Sep 1994 12:57:26 +1200 (NZST)
Organization: (none)

[e-mail] (Ari I Halberstadt) writes:
> >> Byte  plane[maxX][maxY];
> >>
> >> for (i=0;i<maxX;i++)
> >>   for (j=0;j<maxY;j++)
> >>     plane[i][j] = 0;
> >>
> >> ---
> >>
> >> Believe it or not, this is a bottleneck in my program.
> >> I need to make this as fast as possible on the PPC.
> >>
> >> Any advice would be appreciated.
> >
> >The quality of code generation doesn't matter much here -- it's all
> >in how efficiently you bash the memory subsystem.
>
> Actually, the quality of code generation is quite important. Compilers
> can do all sorts of tricks to speed up loops like the above. Things
> that are often done manually, such as loop unrolling, pointer
> arithmetic, common subexpression elimination, etc. can all be handled
> by the compiler. And the compiler may be better suited to make decisions
> on pipelining instructions for a RISC processor.

I stand by my original statement -- the quality of code generation in this
loop matters not at all.

A 60 MHz PPC 601 is capable of writing into its cache RAM at 240 MB/sec.
A PowerMac 6100/60 has a memory subsystem capable of copying about
20 MB/sec (using BlockMoveData, for instance).

This huge discrepency (a factor of more than 10:1) means that it virtually
doesn't matter if your program uses ten instructions where one would have
been enough -- assuming that you are wanting to zero a block of memory
that is larger than your cache.

Loop unrolling, pointer arithmetic, common subexpression elimination -- none
of these matter in this case.  I'm perfectly capable of using these when
they help -- and you'll often see me advocate such things here.

This is not one of those times.

What *does* help, and help more than anything you suggested, is to tell the
processor that it doesn't have to read the memory before it writes new
contents to it.  This results in an instant doubling of speed.

You've got to understand what's going on, not just blindly apply the same
trick in every case.

-- Bruce

---------------------------

>From [e-mail] (Marianne Lee)
Subject: Inside Mac on CD-ROM
Date: 16 Sep 1994 04:58:51 -0700
Organization: University of Southern California, Los Angeles, CA

I want to start programming on the Mac soon and so I ordered the new
Inside Macintosh on CD-ROM.  It seems like a great deal because it has
all the info of the current Inside Macs at a fraction of the price.
One of my friends told me that with 7.5 out now, the old Inside Macs
might get out of date soon.  Is it worth it to get this CD-ROM then?

+++++++++++++++++++++++++++

>From [e-mail] (Paul L. Suh)
Date: Fri, 16 Sep 1994 11:00:38 -0400
Organization: UPenn Grad Econ

In article <35c19r$[e-mail]>, [e-mail] (Marianne Lee) wrote:

> I want to start programming on the Mac soon and so I ordered the new
> Inside Macintosh on CD-ROM.  It seems like a great deal because it has
> all the info of the current Inside Macs at a fraction of the price.
> One of my friends told me that with 7.5 out now, the old Inside Macs
> might get out of date soon.  Is it worth it to get this CD-ROM then?

Actually, the thing to do is subscribe to the APDA monthly developer
mailing.  It includes quarterly issues of Develop magazine, plus monthly
CD-ROMs.  The CD-ROMs are of 3 types: System Software, Toolkit, and
Reference Library.  They are sent out one per month on a rotating basis.
In particular, the Ref Lib CD has the entire new IM plus all of the
current Tech Notes.  Since this is updated every three months, you'll
never have to worry about being out of date!


--Paul

+++++++++++++++++++++++++++

>From [e-mail] (Aaron Bratcher)
Date: Fri, 16 Sep 1994 18:20:03 GMT
Organization: University of Chicago

In article <[e-mail]>,
[e-mail] (Paul L. Suh) wrote:

> Actually, the thing to do is subscribe to the APDA monthly developer
> mailing.  It includes quarterly issues of Develop magazine, plus monthly
> CD-ROMs.  The CD-ROMs are of 3 types: System Software, Toolkit, and
> Reference Library.  They are sent out one per month on a rotating basis.
> In particular, the Ref Lib CD has the entire new IM plus all of the
> current Tech Notes.  Since this is updated every three months, you'll
> never have to worry about being out of date!
>
>
> --Paul

I thought it was stated on this channel that the monthly mailings were not
going to include the new IM any more.

--
Aaron L. Bratcher
University of Chicago

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (alyx)
Date: Fri, 16 Sep 1994 21:03:06 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
[e-mail] (Aaron Bratcher) wrote:

> In article <[e-mail]>,
> [e-mail] (Paul L. Suh) wrote:
>
> > Actually, the thing to do is subscribe to the APDA monthly developer
> > mailing.  [...]
>
> I thought it was stated on this channel that the monthly mailings were not
> going to include the new IM any more.
>

The _Developer CD Series_ will continue to include the complete IM.  The
_develop magazine Bookmark CD_ will contain a core set (Files, Memory, TB,
More TB, Imaging w/QD) and rotate through the rest a couple at a time.

+++++++++++++++++++++++++++

>From [e-mail] (Dr. Jon Gerard Temple)
Date: 17 Sep 1994 03:49:01 GMT
Organization: Naval Research Laboratory

In article <[e-mail]>
[e-mail] (alyx) writes:

> In article <[e-mail]>,
> [e-mail] (Aaron Bratcher) wrote:
>
> > In article <[e-mail]>,
> > [e-mail] (Paul L. Suh) wrote:
> >
> > > Actually, the thing to do is subscribe to the APDA monthly developer
> > > mailing.  [...]
> >
> > I thought it was stated on this channel that the monthly mailings were
not
> > going to include the new IM any more.
> >
>
> The _Developer CD Series_ will continue to include the complete IM.  The
> _develop magazine Bookmark CD_ will contain a core set (Files, Memory, TB,
> More TB, Imaging w/QD) and rotate through the rest a couple at a time.


Folks: You can always just backorder the Develop Bookmark CD issue #17
for $13, direct from d e v e l o p. (They even have a 1-800 toll free
number :) It has the complete New Inside Mac collection on it.  I did
this and thus was not affected by Develop's decision to leave them off
of newer BookMark CDs (my subscription began with issue #18, the first
one that was affected).  The last I checked, $13 was quite a bit less
than the $99 that will be charged for the new CD.  It's a great deal!

+++++++++++++++++++++++++++

>From [e-mail] (Marianne Lee)
Date: 16 Sep 1994 22:16:11 -0700
Organization: University of Southern California, Los Angeles, CA

[e-mail] (Dr. Jon Gerard Temple) writes:

>Folks: You can always just backorder the Develop Bookmark CD issue #17
>for $13, direct from d e v e l o p. (They even have a 1-800 toll free
>number :) It has the complete New Inside Mac collection on it.  I did
>this and thus was not affected by Develop's decision to leave them off
>of newer BookMark CDs (my subscription began with issue #18, the first
>one that was affected).  The last I checked, $13 was quite a bit less
>than the $99 that will be charged for the new CD.  It's a great deal!

So is there any new stuff or anything useful in the new CD?  Why would
Apple release such a thing if it were already available at $13?  Is it
purely marketing?

BTW, when is the next develop issue coming out?  I ordered a subscription
last month and was wondering when the I'm going to get the first one.

+++++++++++++++++++++++++++

>From [e-mail] (Neil Ticktin)
Date: Sun, 18 Sep 1994 18:54:02 GMT
Organization: MacTech Magazine/Xplain Corporation

In article <35c19r$[e-mail]>, [e-mail] (Marianne Lee) wrote:

>> I want to start programming on the Mac soon and so I ordered the new
>> Inside Macintosh on CD-ROM.  It seems like a great deal because it has
>> all the info of the current Inside Macs at a fraction of the price.
>> One of my friends told me that with 7.5 out now, the old Inside Macs
>> might get out of date soon.  Is it worth it to get this CD-ROM then?

Marianne,

You've gotten many positive comments on the develop Bookmark CD.  Let me
give you some other bits of information.  You can order develop and
related things through APDA. Here are some addresses and phone numbers you
may find useful:

To recieve an APDA catalog (development tools and documentation):
  APDA
  P.O. Box 319
  Buffalo, NY  14207-0319
  Phone: [phone] (U.S.A.)
         1 800 637-0029 (Canada)
         716 871-6555 (international)
         716 871-6511 (FAX)
  AppleLink: APDA
  E-Mail: [e-mail]
  CompuServe: 76666,2405

In addition, there's a CD from Addison-Wesley that is shortly going to
ship (if it isn't already).  This will contain all of the New IM volumes
(as I understand it).  I believe it is priced in the $80-130 price range.
This is a DocViewer type CD and doesn't really have searching or hypertext
capabilities.

Finally, there's THINK Reference by Symantec.  TR is the _old_ Inside
Macintosh Volumes 1-6.  If you are going to do "standard" Macintosh
programming and not take advantage of anything beyond the basic System 7
technologies, this will cover what you need.  The best part about TR is it
extensive hyperlinks and searching -- far better than any other solution
today.

If you want more info on the Bookmark CD, call APDA.  If you want more
info on the AW CD, you can get that from APDA or our mail order dept.  If
you want TR, you can get it at your local dealer, or you can buy our
MacTech CD which has TR bundled with it.  Our customer service dept can
help you with anything from our Mail Order Dept.

Hope it helps,

Neil Ticktin
MacTech Magazine

- ---------------------------------------------------------------------
           Neil Ticktin, MacTech Magazine (formerly MacTutor)
PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: [phone]
 For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain
  [e-mail] * [e-mail] * [e-mail]
[e-mail] * [e-mail] * [e-mail]
   [e-mail] * [e-mail] * [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Marianne Lee)
Date: 18 Sep 1994 11:30:50 -0700
Organization: University of Southern California, Los Angeles, CA

[e-mail] (Neil Ticktin) writes:
>In addition, there's a CD from Addison-Wesley that is shortly going to
>ship (if it isn't already).  This will contain all of the New IM volumes
>(as I understand it).  I believe it is priced in the $80-130 price range.
>This is a DocViewer type CD and doesn't really have searching or hypertext
>capabilities.

No searching or hypertext on the NIM CD?  How about the IMs on the develop
CDs, do they have any type of indexing or easy way to look up things?

Just a question, how many of you would prefer the NIM CD over having the
develop version?  Buying develops 17 through 19 and getting a subscription
(which I will be doing anyway) is still cheaper than one NIM CD.

+++++++++++++++++++++++++++

>From [e-mail] ( nick.c )
Date: Mon, 19 Sep 94 11:53:45 GMT
Organization: The Pitt, Chemistry

In Article <35i10q$[e-mail]>, [e-mail] (Marianne Lee) wrote:
>[e-mail] (Neil Ticktin) writes:

>>In addition, there's a CD from Addison-Wesley that is shortly going to
>>ship (if it isn't already).  This will contain all of the New IM volumes
>>(as I understand it).  I believe it is priced in the $80-130 price range.
>>This is a DocViewer type CD and doesn't really have searching or hypertext
>>capabilities.
>
>No searching or hypertext on the NIM CD?  How about the IMs on the develop
>CDs, do they have any type of indexing or easy way to look up things?
>
>Just a question, how many of you would prefer the NIM CD over having the
>develop version?  Buying develops 17 through 19 and getting a subscription
>(which I will be doing anyway) is still cheaper than one NIM CD.

    The CD Neil mentions is starting at $99, available from
      SoftPro at 1-617-273-2919 (it was pre-orderable from
      macworld for $80, and will eventually sell for $150).

    It will have indexes and searching, but nothing as exntensive
      and the Think Reference hyperlinks.  It's identical to
      those on the develop CD's.

    I think we'd all prefer to have as many of the NIM on one
      CD as possible.  The question is: is it worth the extra $99.
      Personally, I'm going to pass on the Addison Wesley CD,
      I already have the _develop_ CD's, but I'm sure some folks
      will find $99 worth it to have all the info on one, rather
      than 5 CD's.  Note another option is a subscription to
      the Developer mailing.  For $250, you'll get 12 disks a
      year including ones with all the NIM on one disk, and
      System 7.5.  That alone makes it tempting, the additional
      system enhancements, reference literature, and development
      tools make it a pretty good deal.

                                            -- nick



                                    _/   _/  _/  _/_/_/   _/   _/
     Interet: [e-mail]        _/_/ _/  _/  _/   _/  _/_/_/
      eWorld: nick                _/ _/_/  _/  _/       _/ _/
         CIS: 71232,766          _/   _/  _/   _/_/_/  _/   _/


+++++++++++++++++++++++++++

>From [e-mail] (Neil Ticktin)
Date: Tue, 20 Sep 1994 03:55:10 GMT
Organization: MacTech Magazine/Xplain Corporation

In article <35i10q$[e-mail]>, [e-mail] (Marianne Lee) wrote:

>> No searching or hypertext on the NIM CD?  How about the IMs on the develop
>> CDs, do they have any type of indexing or easy way to look up things?

Marianne,

I'm not 100% sure on this.  If I understood some previous comments,
there's searching within an individual document, but that's it.  There's
no real indexing or searching mechanism across documents.  Hopefully,
someone will correct me if I'm wrong -- but that's how I understand it.

Good luck,

Neil

- ---------------------------------------------------------------------
           Neil Ticktin, MacTech Magazine (formerly MacTutor)
PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: [phone]
 For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain
  [e-mail] * [e-mail] * [e-mail]
[e-mail] * [e-mail] * [e-mail]
   [e-mail] * [e-mail] * [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Dave Johnson)
Date: Tue, 20 Sep 1994 22:07:33 GMT
Organization: Apple Computer

In article <[e-mail]>,
[e-mail] (Neil Ticktin) wrote:

> I'm not 100% sure on this.  If I understood some previous comments,
> there's searching within an individual document, but that's it.  There's
> no real indexing or searching mechanism across documents.  Hopefully,
> someone will correct me if I'm wrong -- but that's how I understand it.

Since the books are all in DoicViewer format, there is good searching
within and across all the books. Using the collections feature in
Docviewer in combination with the query command can be very powerful. Any
DocViewer users out there who don't know about collections and/or Query
should check it (them) out.

Of course, this is true for ANY set of DocViewer documents, not just the NIM
CD.

Dave Johnson

+++++++++++++++++++++++++++

>From [e-mail] (H. M. Rody)
Date: Wed, 21 Sep 1994 07:51:08 -0500
Organization: Intergraph Corporation

In article <[e-mail]>,
[e-mail] (Neil Ticktin) wrote:

> In article <35i10q$[e-mail]>, [e-mail] (Marianne Lee)
wrote:
>
> >> No searching or hypertext on the NIM CD?  How about the IMs on the
develop
> >> CDs, do they have any type of indexing or easy way to look up things?
>
> Marianne,
>
> I'm not 100% sure on this.  If I understood some previous comments,
> there's searching within an individual document, but that's it.  There's
> no real indexing or searching mechanism across documents.  Hopefully,
> someone will correct me if I'm wrong -- but that's how I understand it.

I too believe that this is true.  I am currently programming on NT and Mac
and I have found that the the layout of the Microsoft CDs as far as search
is far better that on the Developer CDs.  The search engines on the
Microsoft CDs can search the whole CD or parts.  This is an area that
Apple can definately improve on.

What about integrating Apple Search into their own CD?  Apple Search looks
like an excellent product.

--
- ----------------------------------------------------------------------
Marshall Rody                            | Intergraph Corporation
UUCP:     ...uunet!ingr!infonode!hrody   | One Madison Industrial Park
INTERNET: [e-mail]                 | Mail Stop GD3002
AT&T:     [phone]                 | Huntsville, AL  35807-4201

+++++++++++++++++++++++++++

>From [e-mail] (alyx)
Date: Wed, 21 Sep 1994 17:15:51 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>,
the usually better-informed [e-mail] (Neil Ticktin) wrote:

> This is a DocViewer type CD and doesn't really have searching [...]
> capabilities.

oh, please.  it's called "Query".  RTFM!!

+++++++++++++++++++++++++++

>From [e-mail] (Don Doumakes)
Date: Mon, 26 Sep 1994 16:41:00 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Sorry for the repetition, folks.  Problem with my offline reader.

--
______________________________________________________________________
Don Doumakes                                       [e-mail]

---------------------------

>From [e-mail] (Bob Bradley)
Subject: Q: Using PPC apps without Shared Libraries?
Date: Mon, 26 Sep 1994 15:00:39 -0800
Organization: SS Software Inc.

I noticed that every application that uses a shared library (including my
own) will not launch if that shared library cannot be found. Is there any
way around this?

I'm using the Thread Manager on a PowerPC in my application and have the
appropriate checks in my application to tell whether or not the Thread
Manager is available and if not, it uses non-Thread Manager code to still
function (it is limited if not using the Thread Manager). The problem is
my code never gets a chance to run since the system says it couldn't find
the ThreadsLib (when the extension isn't loaded).

The System doesn't appear to be very thorough in it's search for the
library either since another application that requires QuickTime wouldn't
run even when QuickTime was installed. I tried copying the QuickTimeLib
and it still didn't work until I re-installed QuickTime.

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 28 Sep 1994 07:49:01 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail]
(Bob Bradley) wrote:

> I noticed that every application that uses a shared library (including my
> own) will not launch if that shared library cannot be found. Is there any
> way around this?
>
> I'm using the Thread Manager on a PowerPC in my application and have the
> appropriate checks in my application to tell whether or not the Thread
> Manager is available and if not, it uses non-Thread Manager code to still
> function (it is limited if not using the Thread Manager). The problem is
> my code never gets a chance to run since the system says it couldn't find
> the ThreadsLib (when the extension isn't loaded).
>
> The System doesn't appear to be very thorough in it's search for the
> library either since another application that requires QuickTime wouldn't
> run even when QuickTime was installed. I tried copying the QuickTimeLib
> and it still didn't work until I re-installed QuickTime.

There are two ways to link code which uses routines from a PPC shared
library.  One is as you describe (a "hard" link), and the Code Fragment
Manager refuses to proceed if a library so linked is not present at the
time the fragment is prepared.  The other is the "soft" link...in this
case the absence of a needed library causes references into that library
to be resolved by CFM into a magic value which will cause an error when
the reference is later used.  It is then up to the using code to protect
itself before using such a reference.

See Inside Mac: Power PC System Software.

There is a case you need to protect against, which means that with most
shared libraries, merely checking Gestalt is not safe enough.  Suppose the
needed library is present at startup time.  The Gestalt selector gets set
up on that basis.  The user drags the Shared Library out of the Extensions
folder and then starts your app.  CFM sees the absence of the library, and
does its magic value thing.  In many cases though, your app's check of
Gestalt suggests that the library is present because the feature it
implements is available.

HOW you do a soft link depends on which development environment you use.
MPW and CodeWarrior can do it.  --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   "Occasionally...astronomers add a second to either June 31 or
    December 31..."   IM: OS Utilities, p 4-12
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Wed, 28 Sep 1994 15:40:30 +0100
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (Bob Bradley) wrote:

>I noticed that every application that uses a shared library (including my
>own) will not launch if that shared library cannot be found. Is there any
>way around this?

Yes:

1) Indlude the shared library with your application

or

2) Import the library "weakly" - in CodeWarrior, it's a flag in
the project window popup menu for the file.

The search path for a shared library is:

* In the Applications' folder
* In the Extensions folder

That's it.


--
  Jon W$E4tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
 "Don't use the Layer Manager"


+++++++++++++++++++++++++++

>From [e-mail] (Willie Abrams)
Date: Wed, 28 Sep 1994 14:58:27 -0500
Organization: OUHSC Center for Telemedicine

In article <[e-mail]>, [e-mail]
(Bob Bradley) wrote:

> I noticed that every application that uses a shared library (including my
> own) will not launch if that shared library cannot be found. Is there any
> way around this?
>
> I'm using the Thread Manager on a PowerPC in my application and have the
> appropriate checks in my application to tell whether or not the Thread
> Manager is available and if not, it uses non-Thread Manager code to still
> function (it is limited if not using the Thread Manager). The problem is
> my code never gets a chance to run since the system says it couldn't find
> the ThreadsLib (when the extension isn't loaded).
>
> The System doesn't appear to be very thorough in it's search for the
> library either since another application that requires QuickTime wouldn't
> run even when QuickTime was installed. I tried copying the QuickTimeLib
> and it still didn't work until I re-installed QuickTime.

Import "weak" (if you are using CodeWarrior, that option is in the little
triangle thingy next to the library) the shared libraries that you are
using, and then check for their presence before calling the routines.

--
Willie Abrams
[e-mail]

Less is more. God is in the details. - Mies van der Rohe

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Thu, 29 Sep 1994 18:01:12 GMT
Organization: ISIS International

[e-mail] (Bob Bradley) writes:

>I noticed that every application that uses a shared library (including my
>own) will not launch if that shared library cannot be found. Is there any
>way around this?

>I'm using the Thread Manager on a PowerPC in my application and have the
>appropriate checks in my application to tell whether or not the Thread
>Manager is available and if not, it uses non-Thread Manager code to still
>function (it is limited if not using the Thread Manager). The problem is
>my code never gets a chance to run since the system says it couldn't find
>the ThreadsLib (when the extension isn't loaded).

If you're using MetroWerks, click on the popup next to the library and
select "soft import". If you do this, make sure you check that the functions
in it actually exist before calling them (you could probably test only one
function at startup). To do it, write something like:

    if (someFunction != NULL)
        someFunction();
--
Mike Cohen - [e-mail]
NewtonMail, eWorld: MikeC / ALink: D6734 / AOL: MikeC20
Home Page: file://ftp.netcom.com/pub/isis/home.html

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Fri, 30 Sep 1994 18:25:32 GMT
Organization: Apple Computer

Jon W{tte, [e-mail] writes:
> The search path for a shared library is:
>
> * In the Applications' folder
> * In the Extensions folder

You forgot:
* In any folder inside the Extensions folder (including aliases to folders.)

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail]
Date: 30 Sep 94 13:08:43 MST
Organization: (none)

In article <[e-mail]>, Jens Alfke
<[e-mail]> writes:
> Jon W{tte, [e-mail] writes:
>> The search path for a shared library is:
>>
>> * In the Applications' folder
>> * In the Extensions folder
>
> You forgot:
> * In any folder inside the Extensions folder (including aliases to
folders.)
>
> --Jens Alfke                           [e-mail]
>                    "A man, a plan, a yam, a can of Spam ... Bananama!"

OW! There goes the trick of putting inactive extesions in the "Inactive
Extensions Folder"...


Lawson

+++++++++++++++++++++++++++

>From [e-mail] (Gregory D. Landweber)
Date: 30 Sep 94 20:21:23 EDT
Organization: Dept. of Math, Harvard Univ.

In article <[e-mail]> [e-mail] (Bob
Bradley) writes:
>I noticed that every application that uses a shared library (including my
>own) will not launch if that shared library cannot be found. Is there any
>way around this?

You need to mark the library as "weak", in which case the system will not
require that it be linked in when the application is launched.  You can
designate the library as "weak" in the CodeWarrior project window (using
the tiny pop up to the right of the library name).  Of course, if you do
so, you'll have to check to make sure that the routines are present before
you call them.  Checking the appropriate Gestalt selectors should be good
enough, but you can double check that a pointer to the routine isn't null

-- Greg
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Fri, 30 Sep 1994 21:04:59 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>,
[e-mail] wrote:

> In article <[e-mail]>, Jens Alfke
<[e-mail]> writes:
> > Jon W{tte, [e-mail] writes:
> >> The search path for a shared library is:
> >>
> >> * In the Applications' folder
> >> * In the Extensions folder
> >
> > You forgot:
> > * In any folder inside the Extensions folder (including aliases to
folders.)
> >
> > --Jens Alfke                           [e-mail]
> >                    "A man, a plan, a yam, a can of Spam ... Bananama!"
>
> OW! There goes the trick of putting inactive extesions in the "Inactive
> Extensions Folder"...

No...just put that folder "beside" the Extensions folder, not inside it.
[Or use Extension Manager, which does that using " disabled" as a
suffix.]  I usually drag things between the real and the corresponding
(disabled) folders, rather than bothering with Extension Manager.  For
things I toggle a lot, I write a (Frontier, but AppleScript will do)
script.

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   Sorry...clever signatures require cleverness, not found here.
   [e-mail]

---------------------------

>From [e-mail] (Peter N Lewis)
Subject: Reading STR# resource - Pascal code
Date: Thu, 29 Sep 1994 12:25:30 +0800
Organization: NCRPDA, Curtin University

>[e-mail] (Erik Pennebaker ) wrote:
>
> ) This is probably a relatively lightweight quesiton, but I couldn't get
> ) a straight answer (or couldn't find a straight answer) from Inside Mac.
> ) I'm writing a program that needs to read strings from STR# resource,
> ) and needs to know how many strings are in this. I've seen this done,
> ) but for some reason mine seemed to read a null string.  If anyoone
> ) could write an quick example of this it would be great....:)

Here is some Pascal code to create, modify, read, and write STR# resources
and handles.
   Peter.

unit MyStrH;

interface

{$IFC undefined THINK_Pascal}
   uses
      Types;
{$ENDC}

   type
      lineIndex = integer;

   function NewStrH: handle;
   procedure ReinitStrH (h: handle);
   function CountStrs (id: integer): lineIndex;
   function CountStrsH (h: handle): lineIndex;
   function GetIndStr (id: integer; index: lineIndex): str255;
   function GetIndStrH (h: handle; index: lineIndex): str255;
   procedure SetIndStr (id, index: lineIndex; s: str255);
   procedure SetIndStrH (h: handle; index: lineIndex; s: str255);
   procedure DelIndStr (id: integer; index: lineIndex);
   procedure DelIndStrH (h: handle; index: lineIndex);
   procedure InsIndString (id: integer; index: lineIndex; s: str255);
   procedure InsIndStrH (h: handle; index: integer; s: str255);

implementation

{$IFC undefined THINK_Pascal}
   uses
      Memory, Resources, ToolUtils;
{$ENDC}

   type
      indexPtr = ^lineIndex;
      indexHandle = ^indexPtr;

   function NewStrH: handle;
   begin
      NewStrH := NewHandleClear(SizeOf(lineIndex));
   end;

   procedure ReinitStrH (h: handle);
   begin
      SetHandleSize(h, SizeOf(lineIndex));
      indexHandle(h)^^ := 0;
   end;

   function CountStrsH (h: handle): integer;
   begin
      CountStrsH := indexHandle(h)^^;
   end;

   function CountStrs (id: integer): lineIndex;
      var
         h: handle;
   begin
      h := GetResource('STR#', id);
      CountStrs := indexHandle(h)^^;
   end;

   function GetIndStr (id: integer; index: lineIndex): str255;
      var
         s: str255;
   begin
      GetIndString(s, id, index);
      GetIndStr := s;
   end;

   function GetIndStrH (h: handle; index: lineIndex): str255;
      var
         count, i: lineIndex;
         s: str255;
         ps: longInt;
   begin
      count := indexHandle(h)^^;
      if (1 <= index) and (index <= count) then begin
         ps := SizeOf(lineIndex);
         for i := 1 to index - 1 do
            ps := ps + BAND(ptr(ord(h^) + ps)^, $FF) + 1;
         BlockMove(ptr(ord(h^) + ps), @s, BAND(ptr(ord(h^) + ps)^, $FF) + 1);
      end
      else
         s := '';
      GetIndStrH := s;
   end;

   procedure SetIndStrH (h: handle; index: lineIndex; s: str255);
      var
         count, i: lineIndex;
         sz: longInt;
         p: longInt;
         err: longInt;
         ps: longInt;
   begin
      count := indexHandle(h)^^;
      sz := GetHandleSize(h);
      if count < index then begin
         SetHandleSize(h, sz + index - count);
         for p := ord(h^) + sz to ord(h^) + sz + index - count - 1 do
            ptr(p)^ := 0;
         indexHandle(h)^^ := index;
         count := index;
      end;
      ps := SizeOf(lineIndex);
      for i := 1 to index - 1 do
         ps := ps + BAND(ptr(ord(h^) + ps)^, $FF) + 1;
      err := Munger(h, ps, nil, BAND(ptr(ord(h^) + ps)^, $FF) + 1, @s,
length(s) + 1);
   end;

   procedure SetIndStr (id, index: lineIndex; s: str255);
      var
         h: handle;
   begin
      h := GetResource('STR#', id);
      HNoPurge(h);
      SetIndStrH(h, index, s);
      HPurge(h);
      ChangedResource(h);
      WriteResource(h);
   end;

   procedure DelIndStrH (h: handle; index: integer);
      var
         count, i: lineIndex;
         sz: longInt;
         err: longInt;
         ps: longInt;
   begin
      count := indexHandle(h)^^;
      sz := GetHandleSize(h);
      if count >= index then begin
         ps := SizeOf(lineIndex);
         for i := 1 to index - 1 do
            ps := ps + BAND(ptr(ord(h^) + ps)^, $FF) + 1;
         err := Munger(h, ps, nil, BAND(ptr(ord(h^) + ps)^, $FF) + 1,
@err, 0); { @err is a safe, non nil addr }
         indexHandle(h)^^ := count - 1;
      end;
   end;

   procedure DelIndStr (id: integer; index: lineIndex);
      var
         h: handle;
   begin
      h := GetResource('STR#', id);
      HNoPurge(h);
      DelIndStrH(h, index);
      HPurge(h);
      ChangedResource(h);
      WriteResource(h);
   end;

   procedure InsIndStrH (h: handle; index: integer; s: str255);
      var
         count, i: lineIndex;
         err: longInt;
         ps: longInt;
         t: string[2];
   begin
      count := indexHandle(h)^^;
      if count >= index then begin
         ps := SizeOf(lineIndex);
         for i := 1 to index - 1 do
            ps := ps + BAND(ptr(ord(h^) + ps)^, $FF) + 1;
         t := '';
         err := Munger(h, ps, nil, 0, @t, length(t) + 1);
         indexHandle(h)^^ := count + 1;
      end;
      SetIndStrH(h, index, s)
   end;

   procedure InsIndString (id: integer; index: lineIndex; s: str255);
      var
         h: handle;
   begin
      h := GetResource('STR#', id);
      HNoPurge(h);
      InsIndStrH(h, index, s);
      HPurge(h);
      ChangedResource(h);
      WriteResource(h);
   end;

end.
--
Peter N Lewis <[e-mail]> - Macintosh TCP fingerpainter
FTP my programs from redback.cs.uwa.edu.au:Others/PeterLewis/ or
amug.org:pub/peterlewis/ or nic.switch.ch:software/mac/peterlewis/

---------------------------

End of C.S.M.P. Digest
**********************


---------------------------------------------------------------------

NOTE:  The following Macintosh file(s) are enclosed with this
message, in BinHex format.  If your mail system does not convert
BinHex files automatically, you will need to transfer the message to
a Mac and run the BinHex application to decode it.

Filename: Zero32Bytes.s.o    Size:  455 bytes

---------------------------------------------------------------------

(This file must be converted with BinHex 4.0)